650 694 5740 



Siemens Medical 



01 :29:02 p.m. 07-25-2008 



7/10 



REMARKS 

Claims 1-16 are pending. In the Office Action of May 12, 2008, claims 1-14 and 16 
were rejected under 35 U.S.C. § 102(e) as being anticipated by Mullen et al. (US 
2003/0140141 Al) ("Mullen"). Claim 15 was rejected under 36 U.S.C. § 103(a) as being 
unpatentable over Mullen. The Applicants respectfully traverse the rejections and request 
reconsideration in view of the following remarks. 
I. REJECTIONS UNDER 35 ILS.C § 102 

Claims 1-14 and 16 were rejected under 35 U.S.C. § 102(e) as being anticipated by 
Mullen. 

Independent claims 1,7, 12 and 16 are set forth above. 

The Abstract of Mullen discloses: "[sjystems and methods for enabling universal 
remote access and display of diagnostic images acquired by diagnostic imaging equipment, 
independent of the identity of the vendor that manufactured the equipment. One system 
includes a local area network; a scanner capable of sending objects formatted in accordance 
with a communications protocol, each object incorporating at least one image frame; and a 
data capture device connected to the local area network and programmed with data capture 
software to capture an object originating from the scanner in response to that scanner being 
specified as an object of diagnosis. This system further includes a communications channel, 
e.g., a virtual private network, for connecting the data capture device to a central service 
facility. The preferred communications protocol is DICOM. In response to an instruction 
from the service center, the data capture device on the LAN captures image files from a 
malfunctioning scanner and forwards them to the service center for diagnosis.'* 

Mullen fails to disclose at least "identifying, automatically by a first device of said 
plurality of diagnostic medical imaging devices, a second device of said plurality of 
diagnostic medical imaging devices available for communication via said network" as 
claimed in claim 1; "identification logic operative to periodically identify, via said network, 
said first diagnostic medical imaging device to other diagnostic medical imaging devices 
coupled with said network and receive a response therefrom, said identification logic being 
further operative to recognize other diagnostic medical imaging devices which identify 
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further operative to recognize other diagnostic medical imaging devices which identify 
themselves to said first diagnostic medical imaging device" as claimed in claim 7; "each of 
said plurality of diagnostic medical imaging devices being operative to automatically 
discover at least one other of said plurality of diagnostic medical imaging devices via said 
network and facilitate communications therebetween" as claimed in claim 12; or "wherein 
each of said plurality of diagnostic medical imaging devices comprises means for 
automatically discovering at least one other of said plurality of diagnostic medical imaging 
devices via said network and facilitating communications therebetween" as claimed in claim 
16. 

Mullen discloses instead: 

In addition to storing images internally, modern imaging systems need to be able to 
transfer images to various types of remote devices via a communications network. To 
successfully transfer images, the relevant networking features of the scanner must be 
compatible with the networking features of the destination remote device. See 
Mullen, para. 5 (emphasis added). 

In order to accomplish image transfer, the imaging system must know the 
configuration of the destination remote device prior to attempting to communicate 
with that device. The configuration data for the destination remote device is typically 
inputted to the scanner during software installation by a field engineer, although the 
DICOM network can be configured at any time. When the scanner receives an 
instruction to transmit data to a particular remote device from the system operator, the 
scanner software converts the image data to be transferred into the DICOM format 
required by the destination remote device, based on the configuration data for that 
device stored in the imaging system memory. The scanner also sends a request over 
the network to the destination remote device to open an association, i.e., to connect 
the scanner to the destination remote device. If the remote device responds in the 
affirmative, the scanner and remote device then agree on which device will act as the 
server and which as the client. The scanner also selects the appropriate encoding 
syntax from those accepted by the remote device. Other communication parameters 
are also negotiated. See Mullen, para. 7 (emphasis added). 

The scanner shown in FIG. 1 is designed to communicate with a configured remote 
device only if that device has been "activated". Activation causes the DICOM presets 
manager 30 to configure one of a multiplicity of DICOM tasks 40 in accordance with 
configuration data entered into the system for the associated remote device. That 
particular DICOM task will thereafter remain configured for that type of remote 
device until reconfigured for a different device. Other DICOM tasks are configured 
for other remote devices. See Mullen, para. 28 (emphasis added). 
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In particular, a scanner can be configured to communicate with a DICOM-compatible 
computerized data capture device 52 connected to LAN 50. The data capture device 
52 has a DICOM interface 54 that enables it to send and receive DICOM objects to 
and from the LAN 50. See Mullen, para. 34. 

In particular, as shown by the excerpts above, Mullen merely discloses known manual 
configuration techniques for DICOM-compatible devices. Further, as Mullen is focused on 
sniffing or otherwise intercepting DICOM network communications for the purpose of 
diagnosing device failures, device- to- device configuration is largely ignored. 

The Examiner, without specificity, argues that the following paragraph of Mullen 

discloses Applicants* claims: 

The web server 76 may transmit and receive data to and from the scanners 64 
via the network 74, and to and from the central service facility 66 through a 
firewall 78, particularly with a Point-to-Point Protocol (PPP). Firewall 78 may 
include any of various known security devices for preventing access to central 
service facility 66 except by recognized subscribers and other users. Central 
service facility 66 includes one or more central computers 68 which coordinate 
data exchange between the scanners 64 and service support workstations 70 at 
the central service facility. Workstations 70 may, in turn, be staffed by service 
personnel. Computer 68 may also be coupled for data exchange with one or 
more servers 72 at the central service facility. Moreover, computer 68 or other 
devices at the central service facility 66 may be coupled or configured to be 
coupled to other internal or external networks, such as for exchanging data 
with database 82 through an additional firewall 80. In the presently preferred 
configuration, database 82 may be local to or remote from the central service 
facility 66, and may contain data relating to the service history of particular 
scanners, families of scanners, and the like. Such data is compiled over time 
by transmission from computer 68, and is subsequently accessible by 
computer 68. See Mullen, para. 43. 

However, contrary to the Examiner's assertions, the above excerpt generally describes 
the logical arrangement of devices in the disclosed network but fails to disclose any 
methodologies by which devices may be configured to communicate with other devices over 
a network as claimed. Should the Examiner maintain his rejection, he is respectfully 
requested to point out, with particularity, where each and every limitation of Applicants' 
claims may be found disclosed in the cited reference. 



PACE 9/10 * RCVD AT 7/25/2008 5:25:33 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-5/8 * DNIS:2738300 * CSID:650 694 5740 * DURATION (mm-ss):02^0 



650 694 5740 



Siemens Medical 



01:29:48 p.m. 07-25-2008 



10/10 



For at least these reasons, claims 1,7, 12 and 16 are not anticipated, nor are they 
rendered obvious, by Mullen. Applicants therefore request that the Examiner withdraw this 
rejection of these claims. 

Claims 2-6, 8-1 1 and 13-14 depend from claims 1, 7 and 12 and are therefore 
allowable for the reasons set forth above with regard to these claims. Accordingly, 
Applicants request that the Examiner withdraw the rejections of claims 2-6, 8-1 1 and 1314. 
II. REJECTIONS UNDER 35 U.S.C. § 103(a) 

Claim 15 was rejected under 35 U.S.C. § 103(a) as being unpatentable over Mullen. 
Claim 15 depends from claim 12 and is therefore allowable for at least the reasons set forth 
above with regard to this claim. Accordingly, Applicants request that the Examiner 
withdraw this rejection of claim 15. 



CONCLUSION 

Each of the rejections in the Office Action May 12, 2008 has been addressed and no 
new matter has been added. The Applicant submits that all of the pending claims are in 
condition for allowance and notice to this effect is respectfully requested. 



PLEASE MAIL CORRESPONDENCE TO: 

Siemens Corporation 

Customer No. 28524 

Attn: Elsa Keller, Legal Administrator 

170 Wood Avenue South 

Iselin, NJ 08830 



Respectfully submitted, 

Rosa S. Kim, Reg. No. 39,728 
Attorney(s) for Applicant(s) 
Telephone: 650-694-5330 
Date: ? ll"C^ 
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